The secure Internet Protocol (IPSEC) provides network layer security services for computer devices that communicate using Internet Protocol over public networks. IPSEC is defined in S. Kent et al., IETF Request for Comments (RFC) 2401, RFC 2402, and RFC 2406.
IPSEC services include authentication of data origin, data confidentiality, data integrity, and protection against replay. Such services are provided below the application layer of a networked client. Accordingly, an application executing in the client generally is unaware of, or minimally aware of, the presence of IPSEC protection.
IPSEC can be used either in transport mode or in tunnel mode. Transport mode is most typically applied to protect a network link between two hosts, and is obtained by adding an encapsulating payload (ESP) to data packets, or by adding an authenticating header (AH) after the IP header of data packets to provide end-to-end protection.
Tunnel mode is normally used to secure communications of a remote access client to a server. In tunnel mode, the ESP or AH header is added to the original packet, which is then encapsulated with a new IP header. IPSEC tunnel mode allows IPSEC to be provided by intermediate hosts or security gateways when end-to-end protection is not possible. For example, an IPSEC virtual private network (VPN) can link remote sites of an organization, and the cryptographic data confidentiality service of ESP is used to provide privacy on the Internet links between the sites. Use of IPSEC to support VPNs is a significant application because great cost savings may be realized in replacing fixed private links with VPN-protected public network links.
Another practical application of IPSEC involves communication with mobile users, such as those who use laptop computers, personal digital assistants, smart cellular phones, as well as those who telecommute using desktop computers or workstations. A mobile user may connect to a server of an affiliated organization over the Internet. An IPSEC tunnel, which comprises a pair of IPSEC Security Associations (SA's), is created between the remote access client and a security gateway or firewall at the server or organization.
IPSEC is usually implemented as executable computer program instructions that form a part of the network layer on either a host or a router. For example, in a personal computer that runs the Microsoft Windows operating system, IPSEC may be implemented as a layer of the TCP/IP stack. When the IPSEC layer receives an outbound packet, either from a higher layer or from a forwarding algorithm, the IPSEC layer is required to determine whether to send the packet without IPSEC protection (i.e., pass the packet through), send the packet with IPSEC protection (apply IPSEC), or drop the packet. Such determination is made based on one or more IPSEC policies that are stored in association with the IPSEC layer, or in a data store that is accessible to the IPSEC layer.
Unfortunately, conventional implementations of IPSEC as described herein are vulnerable to attack by intruders.
For example, one problem, which arises in transport mode and tunnel mode, relates to use of domain name service (DNS) servers for resolution of domain names into IP addresses. DNSSEC is a definition of a secure form of DNS service. When DNNSEC is not used in a network, an intruder could modify a response from the DNS server. As a result, the wrong IPSEC policy could be applied, compromising security of the environment. For example, an intruder could modify a packet to specify an incorrect IP address, which would result in passing the packet without encryption. DNSSEC is not widely deployed at present, and numerous policy problems are associated with its deployment within an enterprise or across the Internet (use of dynamic IP addresses is one such problem); as a result, further deployment of DNSSEC is likely to proceed slowly, and many enterprises will continue to choose not to deploy it. Accordingly, there is a need for a way to provide security when IPSEC is used in an environment that lacks DNSSEC.
FIG. 1 is a block diagram that illustrates a network environment in which a DNS attack may occur. FIG. 1 is provided to illustrate a general scenario of attack rather than a scenario involving any particular product or implementation.
In the example environment of FIG. 1, IPSEC is used to protect a network link 106, and operates either using transport mode among hosts, or tunnel mode, between a remote access client host 102 and a target host 104. In this context, client host 102 needs to obtain certain information from target host 104. Client host 102 is communicatively coupled by link 110 to DNS server 112. The network environment also includes a malicious host 108, which is able to respond to a DNS query from the client host 102 directly or through a confederate. In this example, assume that DNS server 112 and client host 102 do not implement DNSSEC, so that no cryptographic protection is applied to DNS queries and responses for resource records managed by DNS server 112 and sent on link 110.
Client host 102 maintains a security policy database 114 that stores IPSEC policy information. In the IPSEC policy on the client host 102, malicious host 108 is part of the set of hosts for which IPSEC is not used. Thus, when the client host sends data to malicious host 108, IPSEC is not applied, and an IPSEC key management daemon is not invoked. Further assume that client host 102 executes an application 116.
In this context, an attack may proceed as follows. The client host application 116 has data to send to the target host 104. Application 116 has the DNS name of the target host 104, which may have been entered by a user. For example, application 116 could be an e-mail transport application, and the user may have composed and sent an e-mail message to a recipient whose mail account is hosted at target host 104; thus, the message header of the e-mail message would include the DNS name of the target host, and application 116 would need to resolve the DNS name into an IP address in order to dispatch the message.
The client host application 116 makes a DNS query on link 110 to DNS server 112 to obtain a list of one or more IP address(es) associated with the target host 104. Malicious host 108 or an attacker replies to the DNS query of the client host 102 with the IP address of the malicious host. The IP layer 117 of client host 102 inspects the security policy database 114 and finds that data to malicious host 108 should be passed without IPSEC protection, because the IP address of the malicious host is not included in any list of IP addresses to which IPSEC applies. Accordingly, data from client host application 116 is passed without protection to the malicious host 108. Thereafter, malicious host 108 can either impersonate the target host 104 or engage in a man-in-the-middle attack.
This vulnerability can be compounded in many environments. For example, assume that an enterprise having the environment of FIG. 1 requires user authentication as part of the application-level protocol. If the user authenticates to the application server by sending a cleartext password, then the attacker can obtain the password.
Several approaches to address this vulnerability are possible. In past one approach, the DNS protocol requests and responses that are sent over link 110 are protected using IPSEC. This approach is problematic, however, because the DNS server 112 may not have IPSEC capability. Also, local IPSEC offers no protection for DNS responses received from a remote DNS server. The latter problem is worsened if DNS server 112 accepts additional data without proper checks.
Still another problem arises from the fact that DNS server 112 normally acts as only one in a plurality of DNS servers arranged in a hierarchy rooted at a root-level DNS server. For clarity, such servers are not shown in FIG. 1, but their location in the Internet is published as part of the DNS protocol. Since the root-level DNS server and first-level DNS server are outside the control of the enterprise that owns or operates client host 102, use of IPSEC protection breaks down when client host 102 sends a query to such a higher level DNS server, because by convention, the higher level servers will not agree to use IPSEC upon receipt of a request to do so from client host 102. Signed resource records have to be used to properly protect the DNS servers.
Therefore, use of IPSEC to protect link 110 is not a workable approach and is not a complete solution.
Another approach is to use DNSSEC to secure communications with DNS server 112 over link 110. When DNSSEC is applied to a DNS zone, the DNS zone has a public key pair. The private half of the key pair is used to sign resource records for the zone. Further, subzones as well as other DNS zones can have their public keys signed by a DNS zone key. The public keys are stored in KEY resource records, and the signatures are stored in SIG resource records, which are defined in the DNS specification as set forth in D. Eastlake, “Domain Name System Security Extensions,” IETF RFC 2535, March 1999. In addition, users can store keys in the DNS, using the KEY resource records. Thus, DNSSEC can provide some of the functionality of a public key infrastructure.
An Internet-wide deployment of DNSSEC would consist of the root signing the high-level DNS zones (.com, org, etc.). These zones would then sign the zones beneath them and so on. A local DNSSEC deployment occurs when an organization uses its own DNSSEC zone key as the root DNSSEC key. Two separate organizations could secure DNS traffic that is exchanged between themselves by cross-certifying each other's DNS zone keys.
However, DNSSEC is not widely deployed at present, and unlikely to be deployed in the near term across the Internet. For organizations that use multiple first-level DNS names (e.g., an enterprise that operates servers at DNS names example.org, example-product.com, and example-service.com), DNSSEC deployment is difficult to manage because no single high-level root key can be used for all domains. The same issue applies to use of DNSSEC in an extranet VPN environment where VPN sites are located in multiple organizations. Further, for many organizations, deployment of DNSSEC would require a complete upgrade of the organizations' DNS infrastructure, which is disruptive, time-consuming, and expensive. Deploying DNSSEC also adds another security dependency, both with respect to software code maintenance and security administration, which can weaken all security of an organization and which imposes additional administrative overhead and expense in managing another security infrastructure.
Technical references that provide additional background regarding this context include: J. Trostle et al., “Implementation of Crossrealm Referral Handling in the MIT Kerberos Client,” Proceedings of the 2001 Network and Distributed Systems Symposium, February 2001, pp. 201-210; D. Eastlake, “Domain Name Security System Security Extensions,” IETF Request for Comments (RFC) 2535, March 1999; J. Linn, “Generic Security Service Application Program Interface Version 2, Update 1,” RFC 2743, January 2000; and T. Dierks et al., “The TLS Protocol Version 1.0,” RFC 2743, January 1999; P. Mockapetris, “Domain Names—Concepts and Facilities,” RFC 1034, November 1987; P. Mockapetris, “Domain Names—Implementation and Specification,” RFC 1035, November 1987; S. Kent et al., “Security Architecture for the Internet Protocol,” RFC 2401, November 1998; S. Kent et al., “IP Encapsulating Security Payload (ESP),” RFC 2406, November 1998; S. Kent et al., “IP Authentication Header,” RFC 2402, November 1998, D. McDonald, “PF KEY Key Management APL Version 2,” RFC 2367, July 1998.
Based on the foregoing, there is a clear need in this technical field for a way to eliminate the need for DNSSEC to provide secure domain name resolution in an environment that uses IPSEC transport mode or remote access tunnel mode to encrypt communications.
In particular, there is a need for a way to provide security for such communications in a way that has minimal impact on the existing information technology infrastructure of an enterprise, and maximum protection against attacks of the type outlined above.